Skip to main content

Methodology & Workflow

The OWASP WSTG Framework​

The OWASP Web Security Testing Guide (WSTG) organizes web application testing into structured phases. Following these phases prevents operators from jumping straight to exploitation without first understanding the application - the most common mistake that causes critical vulnerabilities to be missed.

PhaseWSTG CategoryWhat You're Doing
1Information GatheringUnderstand the application, its tech stack, entry points, and attack surface
2Configuration TestingIdentify misconfigured servers, exposed admin interfaces, insecure HTTP methods
3Authentication TestingTest login mechanisms, password policies, MFA, lockout behavior
4Authorization TestingTest what authenticated users can access that they shouldn't
5Session ManagementAnalyze how sessions are issued, maintained, and terminated
6Input ValidationTest every input for injection flaws (SQLi, XSS, command injection, etc.)
7Business LogicTest application workflows for logical flaws that bypass controls
8API TestingTest REST/GraphQL endpoints for auth, input, and access control flaws

The Operator Mindset​

Automated scanners find the easy things. Manual testing finds everything else. The difference between a tool operator and an effective web pentester is the ability to read an application - to understand what it's doing, how it's handling your input, and where the seams are.

When you look at a web application, ask:

  • What technology stack is this running? (PHP, ASP.NET, Java, Node.js, Python?) Each has common vulnerability patterns.
  • How does authentication work? Token-based? Cookie-based? Is it consistent across the app?
  • What data does the application accept? Where does it go? Is it reflected, stored, or used in a query?
  • What does the application do that users aren't supposed to do? (Access other users' data, skip payment steps, elevate privileges?)
  • What happens when you send unexpected input - an extra field, a null value, a very long string, special characters?
  • What does the error output tell you? Error messages often reveal technology, file paths, query structure, or internal hostnames.
tip

Read the source. Right-click → View Source on every page. Developers leave API keys, internal URLs, commented-out code, hidden form fields, and debug parameters in HTML source and JavaScript files constantly. It takes 30 seconds and routinely reveals attack surface that no scanner will find.

Phase-by-Phase: What to Look For​

Phase 1: Information Gathering (WSTG-INFO)​

You are building a map. Don't skip this.

  • Technology stack: Identify the web server (Apache, nginx, IIS), application framework, backend language, CMS (WordPress, Drupal, Joomla), database hints
  • HTTP headers: Server, X-Powered-By, X-Generator, X-AspNet-Version reveal versions. Set-Cookie reveals session token format
  • SSL certificate: Subject, issuer, SANs - SANs often expose internal hostnames, related subdomains, and development/staging servers
  • robots.txt and sitemap.xml: Actively discloses paths the site owner wants crawlers to avoid - exactly where you look first
  • JavaScript files: Often contain API endpoints, internal hostnames, access tokens, and business logic
  • HTML source comments: Developers comment out debug code, internal paths, credentials, and TODO notes

Phase 2: Configuration Testing (WSTG-CONF)​

  • Open ports beyond 80/443: 8080, 8443, 8888, 9090, 9200 (Elasticsearch), 6379 (Redis), 27017 (MongoDB), 4848 (GlassFish)
  • HTTP methods: Does the server accept PUT, DELETE, TRACE? PUT on a web directory = file upload. TRACE = XST attack
  • Directory listing: Can you browse to /images/, /uploads/, /backups/? If Apache/nginx is misconfigured, you get a file listing
  • Backup and temp files: config.php.bak, index.php~, .env, .git/, web.config.old - these get deployed accidentally constantly
  • Admin interfaces: /admin, /manager, /console, /_admin, /wp-admin, /phpmyadmin, /adminer.php
  • Default credentials: If you find an admin panel, try defaults before anything else

Phase 3–4: Authentication & Authorization (WSTG-AUTHN, WSTG-AUTHZ)​

  • Username enumeration: Does the app tell you if the username doesn't exist vs. if the password is wrong?
  • Password policy: Is there one? Is it enforced? Is there lockout?
  • Brute force protection: Count failed attempts - does the response change? Does the account lock?
  • Password reset flow: What data does it use? Security questions (guessable)? Token in URL (replayable)? Email-only?
  • Privilege escalation: If you have a low-privilege account, can you access admin functions by changing a URL parameter or cookie?
  • IDOR: Can you access another user's data by changing their ID in the URL? /profile?id=1002 → try /profile?id=1001

Phase 5: Session Management (WSTG-SESS)​

  • Cookie flags: Secure (only sent over HTTPS), HttpOnly (not accessible via JavaScript), SameSite (CSRF protection) - missing any of these is a finding
  • Token entropy: Is the session token predictable or sequential? Short tokens?
  • Session fixation: Can you set a session ID before login that persists after authentication?
  • CSRF: On state-changing requests (form submissions, account changes), is there a CSRF token? Is it validated?
  • Session expiration: Does the session expire on logout? Does it expire on timeout?

Phase 6: Input Validation (WSTG-INPVAL)​

Every input is a potential injection point. Check all of them:

  • URL parameters: ?id=1, ?q=search, ?file=report.pdf
  • POST body fields: Form inputs, JSON body fields, XML inputs
  • HTTP headers: User-Agent, Referer, X-Forwarded-For, Cookie values - all can be injection vectors
  • File upload fields: Filename, file content, MIME type
  • JSON/XML APIs: Every field in request bodies

What you're testing at each one depends on the context - a numeric ID field → SQLi/IDOR, a name field → XSS/SQLi, a file path → LFI/path traversal, a URL field → SSRF.

Phase 7: Business Logic (WSTG-BUSL)​

Logic flaws cannot be found by scanners. They require understanding what the application is supposed to do, then testing what happens when you deviate from the expected workflow.

  • Can you skip steps in a multi-step process (e.g., go directly to step 3 of a checkout without completing step 2)?
  • Can you submit negative values in price/quantity fields?
  • Can you replay a one-time-use action (password reset token, voucher code)?
  • Can you race condition a check (two simultaneous requests that both pass a balance check)?
  • Can you access functions that should only be available after completing a prerequisite?

Phase 8: API Testing​

  • Discover the API: Is there a Swagger UI at /api/docs, /swagger, /openapi.json? Does the app reference API endpoints in JavaScript files?
  • Auth bypass: Does the API validate tokens consistently? Try removing the Authorization header entirely
  • IDOR in APIs: /api/users/1001/profile - try other user IDs
  • HTTP method abuse: The GET endpoint may be read-only, but does POST/PUT/DELETE work and skip auth?
  • JWT: Decode the token - what claims are in it? Test for alg: none, weak secret brute force

Overall Workflow Checklist​

Use this as your operational sequence. Each phase has its own section in this AID.

PHASE 1 - RECON & FINGERPRINTING
  [ ] Port scan - identify all web services and open ports
  [ ] Technology fingerprinting - whatweb, HTTP headers, SSL cert
  [ ] WAF detection - wafw00f
  [ ] Manual source review - robots.txt, sitemap.xml, HTML source, JS files

PHASE 2 - CONTENT DISCOVERY
  [ ] Directory/file brute force - feroxbuster/ffuf
  [ ] Virtual host enumeration - ffuf vhost mode
  [ ] Identify admin panels, backup files, exposed .git/.env
  [ ] API endpoint discovery - swagger, JS source mining

PHASE 3 - AUTOMATED SCANNING
  [ ] nikto - quick win scan
  [ ] wapiti - crawl and targeted vulnerability scan
  [ ] Review and triage results - separate real findings from noise

PHASE 4 - AUTHENTICATION & SESSION TESTING
  [ ] Test for username enumeration
  [ ] Check cookie flags and session token format
  [ ] Test password reset flow
  [ ] Brute force login if no lockout detected
  [ ] Test CSRF on state-changing requests

PHASE 5 - INPUT VALIDATION (INJECTION)
  [ ] Manual SQLi probing on all input fields
  [ ] sqlmap on confirmed SQLi vectors
  [ ] Command injection testing
  [ ] SSTI testing (if templating engine detected)
  [ ] XSS testing - reflected, stored, DOM contexts
  [ ] XXE testing - if XML input accepted
  [ ] SSRF testing - if URL/hostname input accepted

PHASE 6 - FILE & PATH ATTACKS
  [ ] File upload - if upload functionality exists
  [ ] LFI/path traversal - if file parameter exists

PHASE 7 - ACCESS CONTROL
  [ ] IDOR testing - enumerate object IDs across user contexts
  [ ] Forced browsing - access admin/privileged paths directly
  [ ] Horizontal/vertical privilege escalation

PHASE 8 - API TESTING
  [ ] JWT decode and testing (jwt_tool)
  [ ] BOLA/BFLA testing
  [ ] GraphQL introspection (if applicable)

Manual vs. Automated: When to Use Which​

SituationApproach
Initial recon and fingerprintingAutomated (nmap, whatweb, wafw00f)
Content discoveryAutomated (gobuster/ffuf)
Broad vulnerability identificationAutomated (nikto, wapiti) as a starting point
Confirming a specific vulnerabilityManual - verify scanner findings by hand
SQLi exploitationSemi-automated (sqlmap after manual confirmation)
XSS, SSRF, XXE, IDOR, logic flawsManual - scanners consistently miss these
Authentication and session logicManual
WAF-protected targetManual - scanners get blocked
caution

Never report a vulnerability based solely on scanner output without manually confirming it. Scanners generate false positives. An unconfirmed finding is not a finding.